home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000417_connolly@pixel.convex.com _Tue Dec 1 18:51:52 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA01941; Tue, 1 Dec 92 18:51:52 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA27242; Tue, 1 Dec 1992 19:04:56 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA14593; Tue, 1 Dec 92 12:04:53 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA24775; Tue, 1 Dec 92 12:04:52 -0600
  10. Message-Id: <9212011804.AA24775@pixel.convex.com>
  11. To: timbl@nxoc01.cern.ch
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: Lets keep the web together 
  14. In-Reply-To: Your message of "Tue, 01 Dec 92 16:52:50 +0100."
  15.              <9212011552.AA01907@www3.cern.ch> 
  16. Date: Tue, 01 Dec 92 12:04:51 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >Getting the protocol code and parsing code right and tracking bugs and external
  21. >changes will be some work, I feel that it is important that we do end up with 
  22. >common code.
  23. >
  24. >I know what it is like to have to maintain code on lots of platforms.
  25. >You have to write the code specially. There are W3 code style guidelines in the
  26. >web which say what we found out to be necessary.  It's a pain. Noone is going
  27. >to support 8 parsers on 12 platforms.
  28. >
  29. >I am therefore a little worried about the proliferation of implementations.
  30. >(I know, I'm rather pleased about it too! :-) I would like to see one or maybe
  31. >two definitive libraries around (two, so to test the first one for  
  32. >self-consistent bugs), but not four. I feel that if there are too many, then  
  33. >there will be cases of little things which work on one but not on the others, 
  34. >because there is not enough support effort for each. And we want to keep the  
  35. >quality high, in terms of reliability, conformance, and portability.
  36.  
  37. Well said. With this in mind, I'd like to take issue with the state
  38. of libWWW:
  39.  
  40. You can't use any of the parts without using the whole
  41. thing: you can't use the parser unless you use the HText
  42. data structures, including the HTMainText global variable!
  43.  
  44. The Gopher processing is intertwingled with everything else too.
  45. There should be a GopherOpen() routine, for establishing
  46. a gopher connection and handling seletors and searches, and a GopherMenu()
  47. routine, that handles application/x-gopher entities just
  48. like text/plain and text/x-html entities are currently handled.
  49.  
  50. Similarly, there should be an FTPOpen, LocalFileOpen, HTTPOpen,
  51. etc routines with an easy way to plug in a WAISOpen routine
  52. when somebody gets around to it.
  53.  
  54. I should be able to add MIMEMessage(), MIMEMultipart(), PostScript(),
  55. etc. format handling routines alongside the text/html and text/plain
  56. routines.
  57.  
  58. There is *no reason* for the NOARGS, ARGS1, ARGS2, etc. macros.
  59. You just use the PARAMS() macro in the header, and use K&R style
  60. in the .c file. The only place where this doesn't work is
  61. with varargs foo.
  62.  
  63. There are #ifdefs for VAX, unix, and ThinkC all over the place.
  64. I'm sure these could be localized.
  65.  
  66. This is why Tony Johnson started from scratch, and why other
  67. implementors will do the same.
  68.  
  69. >If you are thinking of a smart extra to EITHER HTTP or HTML then please define
  70. >it and discuss it here on www-talk.  Don't try just to get it out before the  
  71. >next guy. He is probably doing it too, a different way, and theese are all  
  72. >exciting ideas which benefit from being hacked around on the net.
  73. >
  74. >When the idea has come out, we can put it into a tentative "future" spec
  75. >for comment and everyone can work from it.
  76.  
  77. Again, we see the need for a CSCW platform.
  78.  
  79. I think that if we archived the www-talk mailing list, and built
  80. an HTTP server that would serve the articles up with hypertext
  81. links between folloups etc, it would be a good start.
  82.  
  83. If I code up a server in perl that can do this, will somebody
  84. provide disk space and network access?
  85.  
  86. Dan
  87.